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^ (57) Abstract: Method for building software applications, comprising the steps of linking a plurality of modules (5, 6, 7), each of 
which contain a piece of program code, to form a graph, defining the configuration of the software application by defining at least one 

£J object model on the basis of at least one entity comprising an entity identifier and an entity name, and at least on attribute associated 
with the entity, comprising an attribute identifier, an attribute name, a data type and an identifier for the entity to which the attribute 

^ points, wherein each module (5, 6, 7) is arranged to communicate, during operation, a context to a following module (5, 6, 7) that is 
linked to the module (5, 6, 7) in the graph, the context determining the behaviour of the following module. The invention also relates 

^ to a software application that is produced using the method. 
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Software application and method for building software applications 

The present invention relates to a software application and a method for building 
software applications. 

5 At present software applications are produced in various ways. In a first form a- 

software application is designed as a custom application. This has the disadvantages 
that it is expensive and time-consuming, can contain many errors and has high mainte- 
nance costs. In addition, the company using the application runs the risk that the 
employee with knowledge of the application leaves the company taking all his/her 

10 knowledge with him/her. 

In a second form use is made of standard packages in order to obtain a software 
application with a certain functionality. Disadvantages of such an approach are that the 
application has little flexibility, will have a large amount of unnecessary functionality 
and is difficult to integrate with other software packages and the fact that a high degree 

15 of dependence on the supplier results. 

The aim of the present invention is to provide a software application and a 
method for building software applications making use of standard modules only, where 
the disadvantages of the known methods do not arise or arise to an appreciably lesser 
extent. 

20 Said aim is achieved by a software application of the type defined in the pre- 

amble, wherein the software application comprises a plurality of modules, wherein each 
module comprises a piece of program code, wherein the plurality of modules comprises 
mutual links between modules in order to form a graph, wherein each of the plurality of 
modules contains configuration data for defining at least one object model on the basis 

25 of at least one entity comprising an entity identifier and an entity name, and at least one 
attribute associated with the entity, comprising an attribute identifier, an attribute name, 
a data type and an identifier for the entity to which the attribute refers, and wherein 
during operation a context is communicated by a first module to a following module 
that is mutually linked to the first module in the graph, wherein the context determines 

30 the behaviour of the following module. 

Such a software application has the advantage that technically it requires no cus- 
tomising. Effort is required only for the definition of the functionality of the software 
application by linking the modules to produce a graph and the definition of the configu- 
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ration of the modules. Consequently it will be possible to produce a software applica- 
tion much more quickly and the risk of programming errors is appreciably reduced. 

In a preferred embodiment of the software application according to the present 
invention, the plurality of modules is formed by a plurality of standard modules and 

5 each standard module contains program code with a predetermined base functionality 
and a specific functionality determined by the configuration data 

By making use of standard modules with a certain basic functionality (such as 
display of data) and a specific functionality (such as display of data in a list of specific 
dimensions and with specific layout characteristics) determined by the configuration 

10 data it is possible to build an extensive software application within a short time. Errors 
will be prevented as far as possible by the standard basic functionality and consistent 
use of the configuration data in the standard modules. 

In one embodiment the data type of the at least one attribute is a connection, in 
order to indicate that the at least one attribute is a reference to a further entity, the at 

15 least one attribute also containing the identifier for said further entity. This makes it 
possible to communicate the context from a calling module to a called module, the 
calling module being able to influence the behaviour of the called module. 

In a further embodiment of the software application according to the present in- 
vention the context comprises an attribute restrictor, comprising a tuple of an attribute 

20 identifier and an attribute value and/or an entity restrictor, comprising a tuple of an en- 
tity identifier and an attribute value. Such measures make it possible for a calling mod- 
ule to influence the behaviour of a called module by imposing restrictions on the called 
module. 

The software application according to the present invention can comprise a num- 
25 ber of standard modules which each fulfil a specific function. Preferably, the plurality 
of modules contains an action menu block for presenting choices and giving com- 
mands.. In addition, the plurality of modules can contain an object search block for 
searching for data. The plurality of modules can also contain an object editing block for 
presenting data on a screen and editing the presented data. A user interface for a soft- 
30 ware application can be compiled with the aid of these standard modules. 

A second aspect of the present invention relates to a method for building software 
applications, comprising the steps of linking a plurality of modules, each of which 
contain a piece of program code, to form a graph, defining the configuration of the 
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software application by defining at least one object model on the basis of at least one 
entity comprising an entity identifier and an entity name, and at least one attribute asso- 
ciated with the entity, comprising an attribute identifier, an attribute name, a data type 
and an identifier for the entity to which the attribute refers, wherein each module is 
5 arranged to communicate, during operation, a context to a following module that is 
linked to the module in the graph, the context determining the behaviour of the follow- 
ing module. 

Further embodiments of the present method, corresponding to the abovemen- 
tioned embodiments of the software application according to the present invention, are 
10 defined in appended Claims 10 to 16. 

Using the present method it is possible to build software applications in a simple 
and rapid manner, the advantages cited above in the description of the software appli- 
cation also being obtained. 

In a further aspect of the present invention, a software program product is pro- 
15 vided, such as a compact disc, a floppy disc or a website on a server, containing a soft- 
ware application according to one of Claims 1 to 8. 

In yet a further aspect of the present invention a software program product is pro- 
vided that contains program code which, after loading, provides a processing system 
with the functionality of the method according to one of Claims 9 to 16. 
20 The present invention will be explained in more detail below on the basis of an 

example, with reference to the appended drawings, in which: 

Fig. 1 shows an overview of a number of standard modules for a software appli- 
cation according to the present invention and the possible links between the standard 
modules; 

25 Fig. 2 shows an example of a graph of linked standard modules which forms a 

software application according to the present invention; 

Figs. 3a to 3d show examples of screens that can be displayed by the software 
application example. 

A number of standard type modules which in a software application make inter- 
30 action with a user possible are shown in Fig. 1. Fig. 1 further shows which links be- 
tween the modules are possible. The first standard module shown is an action menu 5. 
The action menu 5 is a module that displays buttons by means of which the user can 
call another module. The second standard module shown is an object editor 6, by 
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means of which data can be manipulated. The final module shown is an object searcher 
7, by means of which it is possible to search for data. 

The standard modules 5, 6 and 7 shown in Fig. 1 can be linked to one another in 
two directions. The action menu module 5 and the object editor module 6 can also be 
5 linked to a module of the same type. It is not possible to call up a further object search 
module 7 from the object search module 7 since it can never be functional to call up 
another search screen from one search screen within a software application. New stan- 
dard modules 5, 6, 7 are added to an application by linking to an already existing mod- 
ule, indicated by the arrows in Fig. 1. It can be deduced from Fig. 1 that (with the use 

10 of three standard modules 5, 6, 7) there are 8 types of links in total, all of which have a 
different functional effect within the software application. 

During operation or running of the software application a specific module 5, 6, 7 
calls the following module 5, 6, 7 in accordance with the graph made. The context of 
each module 5, 6, 7 is determined by the status of relevant surrounding modules 5, 6, 7. 

15 By making use of calls, the context of surrounding modules 5, 6, 7 is transmitted to the 
called module 5, 6, 7. This can take place directly or indirectly via a global data struc- 
ture. 

The configuration of a software application according to the present invention 
comprises a number of details, inter alia a description of an object model, which, in 

20 • turn, is described on the basis of entities and attributes. An entity comprises at least an 
entity identifier (a unique number) and an entity name. An attribute comprises at least 
an attribute identifier (a unique number), a name, a data type and an indicator for the 
entity to which the attribute part refers. The data type can be, for example, an integer or 
a string. The data type can, however, also be of the 'connection' type, which indicates 

25 that an attribute with such a data type is a reference to a further entity. In this case the 
identifier of the further entity is also incorporated in the attribute. The attribute can also 
form part of the key for the entity to which it belongs, as a result of which the entity 
can be uniquely identified with the aid of this attribute. 

According to the invention a software application is able to function in that mod- 

30 ules 5, 6, 7 call one another in accordance with a graph and in doing so transmit a con- 
text to a following module 5, 6, 7. This context determines the behaviour of the mod- 
ule. The context that is transmitted by a calling module 5, 6, 7 to a called module 5, 6, 7 
comprises a list containing attribute restrictors and/or entity restrictors. An attribute 
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restrictor is a tuple of an attribute identifier and an attribute value. For this purpose the 
entities which the called module 5, 6, 7 is going to process and the attributes which 
belong to these must be known in the calling module 5, 6, 1. In some cases the calling 
module 5, 6, 7 does not know which entities the called module 5, 6, 7 is going to pro- 

5 cess. In this case an entity restrictor (a tuple of an entity identifier and an attribute 
value) can be transmitted as context. 

At the start of a software application the context is empty. When a second module 
5, 6, 7 is called by a first module 5, 6, 7 an attribute restrictor and/or an entity restrictor 
can be added to the context. This is dependent on the type of module 5, 6, 7 and the 

10 location within the module 5, 6, 7 where the call takes place (as determined by the con- 
figuration of the module 5, 6, 7 concerned). 

If an attribute restrictor is added, a restriction will be made when the second 
module 5, 6, 7 initialises, where the name of the attribute having an identifier that is 
identical to the attribute identifier of the attribute restrictor is the same as the attribute 

15 value of the attribute restrictor. 

If an entity restrictor is added, the entity identifier is identical to the identifier of 
the entity that is addressed in the first module 5, 6, 7. When the second module 5, 6, 7 
initialises a search will be made, per entity restrictor in the context, for an attribute with 
an entity identical to the entity(ies) that is (are) processed in the second module 5, 6, 7 

20 and with a connection entity that is identical to the entity from the entity restrictor. If an 
attribute is found that meets these criteria, the identifier of that attribute is returned as 
the result. Together with the attribute value from the entity restrictor, the restriction that 
the name of the attribute with the identifier found is the same as the attribute value of 
the entity restrictor is applied. 

25 The list of attribute restrictors and entity restrictors (the context) thus provides a 

number of restrictions which apply to all objects in the second module 5, 6, 7. 

Fig. 2 shows a graph of an example of a software application according to the 
present invention. As the start of the graph, the software application has an action menu 
module 5a, that is linked to a first object search module 7a and a second object search 

30 module 7b. The first object search module 7a is connected by a two-way link to a first 
object editor module 6a, so that the first object search module 7a is able to call the first 
object editor module 6a, but also vice versa. In the same way the second object search 
module 7b is connected by a two-way link to a second object editor module 6b. The 
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graph also further comprises a two-way link between the first object editor module 6a 
and the second object editor module 6b. 

In the case of the modules and the possible links shown in Fig. 1, an attribute 
restrictor or entity restrictor has to be added to the context only in certain cases. In the 
5 case of the link from an object editor module 6 to a further object editor module 6 an 
entity restrictor is added if a selected data element in a first object editor module 6 has 
to be displayed in a second linked object editor module 6 or if related data for a 
selected data element in a first object editor module 6 have to be displayed in a second 
linked object editor module 6. In the case of the link of an object editor module 6 to an 

10 object search module 7 an entity restrictor is added to the context if a search has to be 
made for data related to a selected data element. In the case of a reverse link (from an 
object search module 7 to an object editor module 6) an attribute restrictor is added to 
the context if a selected data element in the object search module 7 has to be displayed 
in an object editor module 6. 

15 The example shown in Fig. 2 relates to an application with regard to a company 

that consists of departments and employees. According to a data model there are two 
entities, Department and Employee, and several staff belong to one Department. In the 
example the Department entity has two attributes, a department identifier (DeptID) and 
department name (DeptName) and the Employee entity has three attributes, an 

20 employee identifier (EmpID), an employee name (EmpName) and a Department. The 
identifier attributes are the keys for the entities. The Department attribute points to the 
Department entity. According to the example, the entities contain the data as shown in 
the following table: 



Department 


Employee 


DeptID 


DeptName 


EmpID 


EmpName 


Department 


101 


Board 


201 


Jansen 


101 


102 


Planning 


202 


Klaasen 


102 


103 


Production 


203 


Karelse 


101 




204 


Pietersen 


103 


205 


Kok 


103 


206 


Hulshof 


102 



25 
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Thus, there are three departments, the Board where Jansen and Karelse work, 
Planning where Klaasen and Hulshof work and finally Production where Pietersen and 
Kokwork. 

The first object search module 7a, by means of which a search for departments 
5 can be carried out, can be called up from the action menu module 5a. From the first 
object search module 7a it is possible to call up the first object editor module 6a to view* 
or edit the data for a department found. It is then possible to return to the first object 
search module 7a for a new search action or to call up the second object editor module 
6b in order to view or edit the data for the associated employees. Analogously, it is also 
10 possible to search for employees from the action menu module 5a and to view data for 
an employee. 

The configuration of this application comprises at least the following entities and 
attributes: 



Entities 


Attributes 


ID 


Name 




ID 


Entity 


Name 


Datatype 


Connection entity 




11 


Department 




21 


11 


DeptID 


Integer 






12 


Employee 




22 


11 


DeptName 


String 








23 


12 


EmpID 


Integer 






24 


12 


EmpName 


String 






25 


12 


Department 


Connection 


11 





15 



If the software application is run it starts at the action menu module 5a, which, 
for example, ensures that a screen as shown in Fig. 3a is displayed. Two buttons 21, 22, 
which are labelled Department and Employee respectively, are defined in the configu- 
ration of the action menu module 5a, which buttons each start the (relevant) associated 

20 object search module 7a, 7b on clicking thereon. The context is empty and thus has no 
influence on the behaviour of the action menu module 5a. If the user clicks on button 
21 (Department), the first object search module 7a is then started. In the configuration 
of this module it is defined that a search will be made for data on entity identifier 11. 
The context of the first object search module 7a is empty; after all, nothing is added to 

25 the context when the first object search module 7a is called up by the action menu 
module 5a. This means that no restrictions are imposed during the search for depart- 
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ments. If, for example, the search is for all departments, all departments will be dis- 
played in a table on the screen by the first object search module 7a, as shown in Fig. 3b. 
The screen then shows a table with title 23 (Name) and three rows 24, 25, 26 contain- 
ing the names of the existing Departments (Board, Planning and Production respec- 
5 tively). 

If the Planning department (row 25) is selected in the screen displayed by the first 
object search module 7a, the first object editor module 6a is started. During this opera- 
tion an attribute restrictor, that is to say the tuple [21,102] is added to the context, 
where 21 is the identifier of the attribute and 102 is the identifier of the department. In 

10 the configuration of the first object editor module 6a to be called up it is now defined 
that data for entity 1 1 must be displayed. If the context were to be empty, all depart- 
ments would then be displayed in this first object editor module 6a. Because the first 
object search module 7a has added the attribute restrictor [21,102] to the context, the 
restriction [DeptED = 102] is applied when retrieving the departments, as a result of 

15 which only the Planning department is displayed, as shown in Fig. 3 c, with a second 
screen 27, in which two fields are displayed, that is to say a first field 28 (102) and a 
second field 29 (Planning). 

The employees in the Planning department can then be displayed in the second 
object editor module 6b by clicking on a button in the screen displayed by the first ob- 

20 ject editor module 6a. For this purpose the first object editor module 6a adds an entity 
restrictor to the context, specifically the tuple [1 1,102], where 1 1 is the identity of the 
entity and 102 the identity of the department In the configuration of the second object 
editor module 6b it is now defined that data for entity 12 have to be displayed. Before 
the second object editor module 6b starts to load data, a search will now first be made 

25 for an attribute of an entity with identifier 12 with entity 1 1 as connection. The attribute 
with attribute identifier 25 meets these criteria. The second object editor module 6b 
now applies Department = 102 as additional restriction when retrieving the employees. 
As a consequence of this only the employees of the Planning department are displayed 
in the screen displayed by the second object editor module 6b (see Fig. 3d). In addition 

30 to the second screen 27 shown in Fig. 3c, a third screen 30 is now also displayed, con- 
taining two fields 31, 32, containing the names of the two employees of the Planning 
department (Klaasen and Hulshof, respectively). The other links in the application 
example function in the same way as the links already described and are therefore not 
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further described in more detail. 

In the example shown the context determines how a specific object (such as the 
display screen 30 in Fig. 3d) behaves (or the appearance of this object). As will be clear 
to those skilled in the art, the context can be used to determine the behaviour or the 
5 appearance of multiple objects. In this context consideration can be given, for example, 
to the display in a separate list of additional data relating to the employees displayed in 
fields 31 and 32, which additional data relate solely to the department-related data for 
the employees. 
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CLAIMS 

t 

i 

1. Software application comprising a plurality of modules (5, 6, 7), 
wherein each module (5, 6, 7) comprises a piece of program code, 

5 wherein the plurality of modules (5, 6, 7) comprises mutual links between 

modules in order to form a graph, 

wherein each of the plurality of modules (5, 6, 7) contains configuration data for 
defining at least one object model on the basis of at least one entity comprising an en- 
tity identifier and an entity name, and at least one attribute associated with the entity, 
1 0 comprising an attribute identifier, an attribute name, a data type and an identifier for the 
entity to which the attribute points, 

and wherein during operation a context is communicated by a first module (5, 6, 
7) to a following module (5, 6, 7) that is linked to the first module (5, 6, 7) in the graph, 
wherein the context determines the behaviour of the following module (5, 6, 7). 

15 

2. Software application according to Claim 1, wherein the plurality of modules 
(5, 6, 7) is formed by a plurality of standard modules and each standard module (5, 6, 
7) contains program code with a predetermined base functionality and a specific func- 
tionality determined by the configuration data. 

20 

3. Software application according to Claim 1 or 2, wherein the data type of the at 
least one attribute is a connection, in order to indicate that the at least one attribute is a 
reference to a further entity, the at least one attribute also containing the identifier for 
said further entity. 

25 

4. Software application according to Claim 1, 2 or 3, wherein the context contains 
an attribute restrictor, comprising a tuple of an attribute identifier and an attribute 
value. 

30 5. Software application according to one of the preceding claims, wherein the 

context contains an entity restrictor, comprising a tuple of an entity identifier and an 
attribute value. 
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6. Software application according to one of the preceding claims, wherein the 
plurality of modules (5, 6, 7) contains an action menu block (5) for presenting choices 
and giving commands. 

5 7. Software application according to one of the preceding claims, wherein the 

plurality of modules (5, 6, 7) contains an object search block (7) for searching for data. 

8. Software application according to one of the preceding claims, wherein the 
plurality of modules (5, 6, 7) contains an object editing block (6) for presenting data on 

10 a screen and editing the presented data. 

9. Method for building software applications, comprising the steps of: 

linking a plurality of modules (5, 6, 7), each of which contain a piece of program 
code, to form a graph; 

15 defining the configuration of the software application by defining at least one 

object model on the basis of at least one entity comprising an entity identifier and an 
entity name, and at least one attribute associated with the entity, comprising an attribute 
identifier, an attribute name, a data type and an identifier for the entity to which the 
attribute refers, 

20 wherein each module (5, 6, 7) is arranged to communicate, during operation, a 

context to a following module (5, 6, 7) that is linked to the module (5, 6, 7) in the 
graph, the context determining the behaviour of the following module. 

10. Method according to Claim 9, wherein the plurality of modules (5, 6, 7) is 
25 formed by a plurality of standard modules and each standard module (5, 6, 7) contains 

program code with a predetermined base functionality and a specific functionality 
determined by the configuration data. 

11. Method according to Claim 9 or 10, wherein the data type of the at least one 
30 attribute is a connection, in order to indicate that the at least one attribute is a reference 

to a further entity, the at least one attribute also containing the identifier for said further 
entity. 
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12. Method according to Claim 9, 10 or 11, wherein the context contains an 
attribute restrictor, comprising a tuple of an attribute identifier and an attribute value. 

13. Method according to one of Claims 9 to 12, wherein the context contains an 
5 entity restrictor, comprising a tuple of an entity identifier and an attribute value. 

14. Method according to one of Claims 9 to 13, wherein the plurality of modules 
(5, 6, 7) contains an action menu block (5) for presenting choices and giving com- 
mands. 

10 

15. Method according to one of Claims 9 to 14, wherein the plurality of modules 
(5, 6, 7) contains an object search block (7) for searching for data. 

16. Method according to one of Claims 9 to 15, wherein the plurality of modules 
15 (5, 6, 7) contains an object editing block (6) for presenting data on a screen and editing 

the presented data. 

17. Software program product comprising a software application according to one 
of Claims 1 to. 8. 

20 

18. Software program product comprising program code which, after loading, 
provides a processing system with the functionality of the method according to one of 
Claims 9 to 16. 



25 



******* 
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